1. Field of the Invention
The present invention generally relates to the convergence of addressably disparate IP nodes and networks. More particularly, the present invention relates to coupling together IPv4 and IPv6 nodes without the use of an application level gateway.
2. Background Information
Coupling computers and computer-related equipment together in networks has enabled a variety of capabilities and services that are not possible with standalone machines. Examples of such capabilities and services include file sharing and email. The Internet permits entities which have incompatible addressing schemes to seamlessly and efficiently share information using network address translators.
Computer networks include not just the computers (called “nodes”) that communicate with each other, but also an infrastructure that coordinates the transfer of data from one end node to another. The communication infrastructure includes switches, routers and other devices to provide, from the user's viewpoint, a transparent communication mechanism. Each node in the network is assigned an address referred to as an Internet Protocol (“IP”) address and each node is accessible via its IP address. Thus, in general, a node wishing to send data to another node needs to know the IP address of the destination node. Armed with the destination IP address, the source node hands the data and the destination address to the communication infrastructure which then routes the data in an appropriate manner to the desired destination node. The data transmission also includes the address of the source node so that the destination node will be able to send messages back to the source node.
Because IP addresses are quite lengthy and hard to remember, end nodes are often assigned an easier to remember alphanumeric name also called a domain name. Domain names are typically in the format of “hostname.companyname.com”. An Internet service called Domain Name System (“DNS”) converts domain names to their associated IP addresses. This permits a source node to send the domain name of the destination node to the DNS. The DNS looks up the IP address corresponding to the requested domain name and provides the IP address back to the source node. The source node then uses the IP address provided by DNS to establish a communication session with the desired destination node. Typically, application software automatically coordinates the brief communication with DNS to obtain the IP address of the destination in a manner transparent to the user.
The communication infrastructure works remarkably well despite the presence on the network of a wide variety of computers and other types of device owned and operated by a wide variety of disparate organizations. This is true because a variety of standards have been promulgated which specify various aspects of how devices on the network are to communicate with each other. As long as the entities coupled to the network adhere to the accepted standards, the network works fine.
One such standard, which has been used since at least the 1970's is called the Internet Protocol version 4 (“IPv4”). The IPv4 standard provides a great deal of communication specifics, many of which are unnecessary to understand for the purpose of the technology described in this disclosure. One feature of IPv4, however, relevant to this disclosure is its addressing scheme. The IPv4 addresses are 32 bit addresses. An example of an IPv4 address is 132.146.243.30. Although initially, 32 bit addresses provided more than enough unique addresses to accommodate the total number of users, in recent years there has been an explosion in the number of users of IP networks quickly exhausting the addresses provided by IPv4.
For that and other reason, Internet Protocol version 6 (“IPv6”) was created. IPv6 is a new version of the IP protocol designed to modernize IPv4. IPv6 has a number of advantages over IPv4 that allows for future Internet growth and will simplify IP configuration and administration. IPv6 specifies 128 bit IP addresses which solves the IP address shortage problem noted above. IPv6 also includes an addressing model that promotes aggressive route aggregation and a power autoconfiguration mechanism. Over time, it is expected that Internet growth will result in widespread adoption of IPv6. Already, IPv6 is becoming more and more widely used and accepted.
There is expected to be a long transition period during which it will be necessary for IPv4 and IPv6 nodes to coexist and communicate with one another. IPv4 nodes are incapable of correctly processing the longer IPv6 IP addresses. Thus, a strong, flexible set of IPv4-to-IPv6 transition and coexistence mechanisms are required during this transition period. One such mechanism is the Network Address Translation-Protocol Translation (“NAT-PT”) mechanism. In general, NAT refers to the translation of an IPv4 address into an IPv6 address, and vice versa. The data transmission in an IP network typically include header information and a data payload. The header information include the source IP address, destination IP address, a checksum and other information relevant to the routing of the data payload to the destination node. The checksum is a value that is calculated based on the contents of the rest of the header information. The checksum is used by the destination node to determine whether any errors have occurred in the header during transmission. NAT-PT translates the header in a suitable manner so as to provide a seamless transfer between IPv4 and IPv6 networks.
The following example may help understand this process, although a more detailed explanation can be found in numerous references such as the Network Working Group's “Network Address Translation-Protocol Translation (NAT-PT)” memo dated 2000, incorporated herein by reference, and available on-line at www.ietf.org/rfc/rfc2766.txt?number=2766. By way of example, FIG. 1 shows an IPv6 node 20 capable of communicating with an IPv4 node 26. The IPv6 node 20 has a v6 address of FEDC:BA98:7654:3210::1 and the IPv4 node 26 has a v4 address of 132.146.243.30 NAT-PT node 22 is included to provide the necessary address and protocol translations. The NAT-PT 22 has access to a pool 24 of addresses including all IP addresses from the IPv4 subnet 120.130.26.0/24.
If the IPv6 node 20 wishes to send a session initialization packet to the IPv4 node 26, the NAT-PT 22 locally allocates an address (e.g., 120.130.26.10) from its pool 24 of addresses and the outgoing packet is translated to IPv4. That is, the NAT-PT 22 replaces the source address (FEDC:BA98:7654:3210::1) of the IPv6 node 20 in the outgoing packet with the temporarily assigned v4 address (120.130.26.10) from the pool of v4 addresses. Further, the packet's header checksum is recomputed based on the new IPv4 address. In general, NAT-PT translates the packet header to a suitable IPv4 packet and forwards the packet to the IPv4 node. The translation parameters are cached for the duration of the session and the IPv6-to-IPv4 mapping is retained by NAT-PT 22.
The IPv4 node 26 receives the packet and uses the NAT-PT assigned temporary IPv4 source address (120.130.26.10) as the address for return messages. Any returning traffic towards the IPv6 node 20 will be recognized by NAT-PT 22 as belonging to the same session. NAT-PT 22 will use the state information to translate the packet. NAT-PT replaces the IPv4 address originally provided to the IPv4 node as the source address with the true IPv6 address (FEDC:BA98:7654:3210::1). The translated packet can now be routed inside the IPv6-only stub network as normal.
NAT-PT permits v4 and v6 nodes to communicate with one another regardless of which node initiates the session. The example above depicts the process when the v6 node initiates the session. Although not specifically described herein, the NAT-PT 22 can also temporarily allocate a v4 address to a session when the IPv4 node initiates the session.
Translating the header information for conversion between v4 and v6 nodes and networks is relatively straightforward. Translating the packet's data payloads, however, often is much more complicated and burdensome. Whereas the packet header is formatted according to a standard, the data payloads are application specific. Packet headers are easily translated because the location of the IP addresses and checksums are dictated by the applicable standards. Data payloads are free form and generally can be formatted however the application layer protocol designer desires. An example of when a data payload would need to be translated between IPv6 and IPv4 is for “voice-over-IP” applications. Voice-over-IP generally refers to Internet-based telephony in which users have a “phone” conversation with each other solely via the Internet and not using the standard telephone system. When a call is initiated, the calling node submits a packet to the receiving node that includes the calling node's IP address. This source address is typically included in the packet's header as well as the packet's payload. Not only does the source address in the header need to be translated as described above, but so does the payload's source address. NAT-PT only translates headers, not payloads. A different mechanism is needed to address the payload translation issues.
A currently popular approach is through the use of an Application Level Gateway (“ALG”). An ALG is a separate piece of logic that is specially designed for a particular application protocol. An ALG not only replaces the IPv6 address and IPv4 address in the payload, but also keeps track of some context information associated with the application and NAT-PT. The ALG generally is complicated and consumes computational power. If the application protocol changes to a new version, the ALG must be changed accordingly. Moreover, the continued maintenance and updating of ALGs is very labor intensive and costly. Other approaches to solving the payload translation problem have been discussed and/or are available. Such other approaches include Middlebox Communication Architecture, Application Layer Protocol Extension and Realm Specific IP. These approaches are still early in their development and are not fully tested and working. Accordingly, a better solution is needed than what is currently available today to address the IPv4-IPv6 payload conversion issue described herein.
Another problem to be considered when converting between IPv4 and IPv6 is how to handle applications for which a single control session is insufficient complete. A NAT-PT control session is generally defined as the set of traffic that is managed as a unit for translation by NAT-PT. A control session remains active until affirmatively closed by one of the nodes or upon expiration of a timeout timer. That is, if the nodes do not communicate with each other for a predetermined period of time, the session is automatically ended and the NAT-PT temporarily assigned v4 address is returned to the pool to be recycled for another control session. If, for example, an Internet voice conversation is occurring and the users do not say anything to each other for a period of time, their control session will timeout and end. This termination of temporary IPv4 address assignment is not known to the voice application. The VoIP application will be broken and stopped. The phone conversation can continue only upon reestablishing a new VoIP control session and, in the case of Internet telephony between IPv4 and IPv6 nodes, a new IPv4 address. Terminating and then reestablishing a control session between the two nodes interrupts the phone conversation and is thus undesirable. Further, the new IPv4 address affects the translation process. Moreover, a solution to this problem is also needed.